This disclosure relates to debugging circuitry on an integrated circuit chip. The disclosure is particularly relevant to functionally testing circuitry on an operational integrated circuit chip.
In the past, an embedded system which had multiple core devices (processors, memories etc.) would have been incorporated onto a Printed Circuit Board (PCB) and connected on the PCB via buses. Traffic in the embedded system was conveyed over these buses. This arrangement was convenient for debugging the core devices, because debugging tools such as oscilloscopes and logic analyzers could be attached to the PCB's buses allowing direct access to the core devices.
Market demand for smaller products coupled with advances in semiconductor technology has led to the development of System-on-Chip (SoC) devices. In a SoC, the multiple core devices of an embedded system are integrated onto a single chip. In a SoC, the traffic in the embedded system is conveyed over internal buses, thus connection of debugging tools directly to the system bus is no longer possible. The resulting reduced access coupled with an increasing quantity of data being transported around the chip (due to developments of SoC technology leading to integration of multiple processing cores and higher internal clocking frequencies), has reduced the ability of external debugging tools to find and solve bugs within the system in the timescales demanded by the industry.
These days, two types of testing are commonly performed to identify problems with a SoC device prior to it being placed on the market. The first type of test is known as Design for Test (DfT). DfT is implemented on a chip which is operating in a dedicated test mode. This dedicated test mode is mutually exclusive to the end-use functional mode which the chip operates in the final application product. The purpose of the DfT is to determine if the chip hardware has been manufactured correctly, and to identify any problems if it has not. DfT does not, and is not capable of, testing the operational functionality of the chip. In other words, DfT does not, and is not capable of, testing the functionality of the chip whilst the chip is operating in its end-use functional mode.
The second type of test is known as functional testing. Due to the problems outlined above, functional testing of an embedded system is generally done in a simulation environment. A function is simulated and functional coverage software used to record the outcome. The outcome is then reviewed to determine if the system correctly carried out the function. A problem with simulation environments for hardware circuits is that they are extremely slow compared to the SoC hardware operating in normal conditions (about 1/10,000,000). Thus, functional testing run in simulation environments does not detect timing-related bugs which surface when the SoC is operating at full speed. Additionally, simulation environments tend to simulate each function in isolation. This does not reflect the system's operation of the function in the final application product, where the system will be performing other functions at the same time. Thus, in the final product, the system resource available to the tested function will be less. For example, the system may have to wait to access a bus or memory in order to carry out part of the function. Thus, functional testing run in simulation environments does not detect system resource-related bugs which surface when the SoC is operating in normal conditions in the final application product.
Consequently, once a SoC is released to the market, and being operated at full-speed under normal conditions, bugs surface which were not detected during the functional testing process.
Thus, there is a need for improved functional testing of SoC devices.